Questions on User - Level Device Drivers

T HE microkernel story is full of good ideas and blind alleys. The story began with enthusiasm about the promised dramatic increase in flexibility, safety, and modularity. But over the years, enthusiasm changed to disappointment, because the first-generation microkernels were inefficient and inflexible. • Today, we observe radically new approaches to the microkernel idea that seek to avoid the old mistakes while overcoming the old constraints on flexibility and performance. The second-generation microkernels may be a basis for all types of operating systems, including timesharing, mul-timedia, and soft and hard real time. The inefficient, inflexible first generation inspired development of the vastly improved second generation, which may yet support a variety of operating systems. Traditionally, the word kernel denotes the mandatory part of the operating system common to all other software. The kernel can use all features of a processor (e.g., programming the memory management unit); software running in user mode cannot execute such safety-critical operations. Most early operating systems were implemented by means of large monolithic kernels. Loosely speaking, the complete operating system—scheduling, file system , networking, device drivers, memory management, paging, and more—was packed into a single kernel. In contrast, the microkernel approach involves minimizing the kernel and implementing servers outside the kernel. Ideally, the kernel implements only address spaces, interprocess communication (IPC), and basic scheduling. All servers—even device dri-vers—run in user mode and are treated exactly like any other application by the kernel. Since each serv-er has its own address space, all these objects are protected from one another. When the microkernel idea was introduced in the